Techniques have been developed for multimedia communication involving devices in a limited local network using internal addressing and transport means, also referred to as a private or home network, a LAN (Local Area Network), a residential or office network. In this description, the term “local network” is used to represent any such networks, and the term “device” represents any entity capable of media communication in a local network. The devices in a local network may include any types of entities such as fixed and wireless telephones, computers, media players or “renderers”, media servers and television boxes, the latter also called “STB” (Set Top Box).
UPnP (Universal Plug-and-Play) is a technology for establishing standardised device protocols for communication in a local network between different devices that may use different access technologies, operating systems, programming languages, format standards and communication protocols. Further, DLNA (Digital Living Network Alliance) is a technology for acquiring, storing and accessing digital media content in devices of a local network. The UPnP protocol is utilised by DLNA as an underlying protocol for communication between DLNA-enabled devices within local networks. Such DLNA devices are generally capable of using HTTP (Hyper Text Transport Protocol) as a basic transport mechanism for transfer of media in a local network. In addition, RTP (Real Time Protocol) can also be used for media transport in the local network.
UPnP supports a process called “discovery” in which a device can join a local network, obtain a local IP address, announce its name and IP address, and exchange capabilities and services with other devices in the network. In this description, any functions and protocols installed in devices for the transport, communication, encoding/decoding, storing and playout of media will be referred to as “capabilities” for short.
A network architecture called IMS (IP Multimedia Subsystem) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling and controlling multimedia services and sessions. In order to provide IMS-based services for devices in a limited local network and to enable multimedia communication with entities outside the local network, a gateway called “HIGA” (Home IMS Gateway) has been devised as a solution where the IMS network is used for establishing sessions with external entities.
UPnP also defines a Remote Access Architecture RAA, enabling a remote UPnP device located outside the local network to communicate with UPnP devices located within the local network. In particular, the RAA specifies how to provision and configure parameters required for enabling remote access connections between entities having a Remote Access Server RAS and a Remote Access Client RAC, respectively, generally referred to as a UPnP RA procedure.
FIG. 1 illustrates a typical logic structure in a remote device 100 and in a local gateway 102 of a local network, respectively, for enabling remote access to local devices in the network (not shown) according to the UPnP RA procedure. The local gateway 102 may be an RGW (Residential Gateway) and/or a HIGA. A Remote Access Client“RAC” 100a has been configured in the remote device 100 and a corresponding Remote Access Server “RAS” 102a has been configured in the local gateway 102, which can be done when both are present in the local network since RAC 100a and RAS 102a should be configured and synchronized with matching profiles.
The RAC 100a comprises a Remote Access Discovery Agent“RADA” 100b, and the RAS 102a comprises a corresponding Remote Access Discovery Agent “RADA” 102b, both being configured to exchange discovery or “pairing” messages between the two entities 100 and 102. The RAC 100a further comprises a Remote Access Transport Agent “RATA” 100c and the RAS 102a comprises a corresponding Remote Access Transport Agent “RATA” 102c, both being configured to establish a transport channel for media between the two entities 100 and 102. Effectively, the RATAs 100c, 102c will act as opposite end points for signalling and media communication of the remote access.
Solutions have also been developed to enable a first device to control the transfer of media from a second device to a third device within a local network, often referred to as the “3-box scenario”. For example, a small handheld wireless phone with limited playout capacity may be used as a control device to direct a laptop computer or a media server to stream video media to a large flat screen TV used as media renderer, in order to view the content on a larger screen and with greater quality as compared to both the wireless phone and the laptop computer.
WO 2008/108699 discloses a solution for media transport across two local networks and according to the 3-box scenario above. In this solution, media can be communicated in a session between a device in a first local network and another device in a second local network by means of gateways in each local network, as initiated by means of control messaging over an IMS network using a remote control device present in the first local network. Although the remote control device is present in one of the two local networks, it does not participate in the media communication itself. This solution requires that the remote control device has an IMS client and a valid IMS subscription and that a HIGA is installed at least in the second local network.
Depicting the basics of this solution, FIG. 2 illustrates first and second local networks 200, 202 and an IMS network 204. Networks 200 and 202 comprise residential gateways RGW 200a and 202a, respectively, and at least the second network 202 further comprises a HIGA 202b for communication with IMS network 204.
A remote control device 200b is visiting the first local network 200 which also includes a TV set 200c, while the second local network 202 includes a media server 202c. The user of device 200b has knowledge of media content being stored in server 202c in network 202 which could be his/her home network. As schematically indicated in the figure, IMS signalling between device 200b and HIGA 202b over IMS network 204 is required for realising and controlling the media transfer from media server 202c to TV set 200c. It is thus required that the device 200b is an IMS client having a valid IMS identity, and that the HIGA 202b is likewise an IMS client installed at least in the second local network. It is thus a limitation that no such media transfer across two local networks according to the 3-box scenario is possible unless the above IMS clients are available.
Another limitation with the prior art is that the current UPnP RA (Remote Access) specification itself does not provide for media transfer across different local networks, e.g. for rendering content from a remote location according to the 3-box scenario, but only for media transfer between a remote device and a local network.